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METHOD AND SYSTEM FOR MANAGING THE 
MANUFACTURE OF CUSTOMIZED GOODS 

TECHNICAL FIELD 

5 

The present invention generally relates to customized manufacturing, and 
more particularly to a method and system for managing the production of customized 
goods based on customized orders. 

10 BACKGROUND 

The e-commerce revolution is redefining the sales and marketing strategies of 
many companies, but the revolution typically stops at the factory floor. Generally, 
this has been one of the biggest obstacles for traditional bricks and mortar 
15 companies in their move to an e-commerce world, and the manufacturing industry 
still remains tied to traditional manufacturing models. For example, companies may 
now accept individually customized orders over the Internet, but to be viable a 
business also should have the ability to efficiently manufacture and assemble such 
customized products. 

20 While mass production was the hallmark of yesterday's Industrial Age, mass 

customization should dominate the modern stage of economic evolution-the 
Information Age. Mass customization provides consumers with exactly the products 
they want. Providing automation on demand is becoming a necessity for many 
companies. 

25 In the 1980s, many companies worked to build their supply chains. In the 

1990s, these companies then worked to manage their supply chains. In the 2000s 
companies should generally be prepared to shorten the supply chains or even 
eliminate them. For over 25 years, manufacturers have been implementing 
Enterprise Resource Planning ("ERP"), Supply Chain Management ("SCM"), and 

30 Manufacturing Resources Planning ("MRP")(-II) systems to reduce order fulfillment 
time. Now these technologies have generally formed an ossified barrier separating 
the manufacturer from the customer. For large manufacturing companies using 
traditional channels of distribution, this barrier may be causing inventory levels to 
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increase and service levels to drop. For newly emerging e-commerce companies, 
the Internet now allows end customers to browse and purchase products directly 
from manufacturers on-line. The Internet provides an easy means of permitting a 
customer to order products, for example, with any size, at any time, in any color. A 
manufacturer can easily take the order and process it. Generally, the more difficult 
aspect for the manufacturer is in implementing customized manufacturing to 
complement this streamlined ordering process. 

The Internet age is distinguished from the industrial age by a number of 
characteristics, as shown in Table 1 . 



Differences Between the Industrial Age and Internet Age 


Industrial Aae 


Internet Aae 


Product-centric 


Customer-centric 


Proprietary 


Interoperability 


Scarcity 


Ubiquity 


Mass Production 


Mass Customization 


Scale 


SCALE 


Time 


TIME 


Traditional/Static 


Change/Fluid 


Individual 


Collective 


Supply Chain 


Customer Chain ! 



Table 1 



Generally, the economy's progression to customization arises from the free 
1 5 market's relentless drive to bring what each consumer buys closer to what that 

consumer wants. The manufacturer is generally being driven to mass customization- 
-nimble operations in which products are built-to-order with short lead times, while 
maintaining mass production costs. Generally, the market for mass customization 
may be divided into three horizontal segments: 

20 

(1 ) Traditional manufacturers that want to move towards mass 
customization in order to improve responsiveness to fluctuating market 

2 



5 



10 
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conditions, to simplify the supply chain, or to implement build-to-order 
.t programs for trading partners or end customers. 

(2) Mass Customization/Made-To-Order companies that are focused 
on selling manufactured products directly to end customers (businesses or 

5 consumers). This market includes bricks and mortar catalog companies that 

want to move towards an e-commerce model. 

(3) Virtual Supply Chain companies that have products made partly by 
outsourced or 3 rd party manufacturers, and need to manage their orders 
throughout this process. 

10 

The Internet is providing an economical solution that allows companies to 
target individuals, and to allow the individuals to configure and order custom 
products. The world is generally shifting from mass marketing and mass production 
to 1:1 marketing and mass customization. As the level of customization has 

1 5 increased, however, companies have continually responded with an increasing 
number of new products. Each of these new products is assigned a unique Stock 
Keeping Unit ( U SKU B ), which is used for ordering, planning, and manufacturing. The 
number of SKUs has increased by over 500% over the past 10 years, and the 
Internet is causing the pace of new products to increase even more quickly. 

20 One alternative is the trend to move away from a large number of unique 

product codes to a magnitude fewer product groups plus options. Instead of each 
possible option (e.g., bottle size for cosmetics, furniture finish for furniture, hood style 
for textiles) creating its own unique product code, these now only become options to 
a basic product group. Sales configurators can typically easily handle these types of 

25 orders with options. 

One problem, however, is that the manufacturing plants have little processes 
in place to allow them to handle these custom orders. Almost all enterprise 
packages require manufacturing information to be assigned to specific unique 
product codes, and these packages are incapable of handling the effects that options 

30 will have on the manufacturing process (e.g., routings, capacity, labor). Most 

factories establish set manufacturing parameters for each individual SKU or product 
code, but in the newly emerging world of mass customization these unique codes 
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often don't exist. If they do exist, the vast number of unique product codes can make 
manufacturing configuration and maintenance nearly impossible. 

Typically, differently configured products, although similar, create different 
product codes. Companies currently forecast these two items as totally unique 
5 products. Because the forecasts are generally inexact or incorrect, even though the 
two products are almost identical, it is often impossible to change the product label 
once the product is in its final form and stored in a warehouse. 

Traditional ERP and MRP software was designed to optimize the internal 
manufacturing operations of a company. The lack of critical components required for 

10 customer-driven manufacturing requires the manufacturer to significantly increase 
lead times, increase inventory, and reduce customer service - just the problems 
these systems were installed to eliminate. In the past, companies could generally 
invest in better planning and supply chain management technology to alleviate these 
problems. As e-commerce drives customers directly to the factory, however, 

1 5 companies must generally change their way of doing business to respond to 
customer expectations. A new approach is required which would, in effect, allow 
customers to communicate directly with the factory floor. 
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SUMMARY OF THE INVENTION 

These problems are generally solved or circumvented, and technical 
advantages are generally achieved, by a preferred embodiment of the present 
5 invention comprising a system and method for real-time management of mass 
customized and made-to-order manufacturing. The computer-implemented system 
and method may provide for control and optimization of the production of option- 
based customized goods within a manufacturing facility. The system and method 
may synchronize with suppliers of raw materials and also coordinate the delivery of 
10 ordered products. Manufacturing parameters (e.g., process routes, capacity 

requirements, labor needs) may be established dynamically on an order-by-order 
basis. 

In a preferred embodiment, the system and method may be implemented as a 
distributed application and may be remotely driven, for example, via an intranet or an 

15 internet. The application may be implemented as web-based or Internet-based, and 
may be implemented as an Application Service Provider ("ASP"). In a preferred 
embodiment, a customer causes an customized order to be generated. An extend 
Markup Language ("XML") document is created that contains the order information, 
and the XML document is then communicated electronically to the factory for the 

20 processing of the order. E-commerce. orders from customer may be placed directly 
with manufacturers. The customer is placed first, rather than the factory floor, the 
distribution center or the logistics network. 

In a preferred embodiment, Java based e-commerce software ties 
manufacturing directly to orders, while managing factory capacity and labor 

25 constraints. Software modules may communicate with one another, coordinating 
deliverable orders, synchronizing raw materials with bulk work-orders, filling orders, 
and managing assembly, preferably all the way to the distribution center and the 
customer site. The orders not only drive manufacturing, but may also tie directly to 
suppliers to coordinate timely delivery of raw materials. Factory production may be 

30 driven directly by the customer's demand, rather than by forecasts, purchasing 
requirements, or local optimizations. 

In a preferred embodiment, mass customization provides the means for 
manufacturing products to a lot size as close as physically possible to a single unit at 
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about the same cost as traditional mass production methodologies. The flow 
manufacturing algorithms described below may be used to optimize manufacturing 
lead-time within the factory. While current solutions, including ERP and SCM 
systems, were designed to plan and manage a complex supply chain, a preferred 
5 embodiment simplifies the supply chain, effectively letting customers communicate 
directly with the factory. Even manufacturers that utilize distribution may use a 
preferred embodiment to greatly reduce supply chain problems, and assist them in 
managing an environment comprising increasing product options. Such an approach 
is generally complementary to, and not competitive with, existing technologies such 

10 as ERP, SCM, and MES, which treat the factory as a black box. 

In accordance with a preferred embodiment of the present invention, a 
computer implemented method for managing mass customized product 
manufacturing in a factory comprises receiving an order for a customized product, 
the order comprising base information for the customized product; dynamically 

15 determining manufacturing parameters for manufacturing the customized product 
based on the product base information; and scheduling manufacture of the 
customized product in the factory based upon finite capacity loading of the factory 
using the manufacturing parameters. 

In accordance with another preferred embodiment of the present invention, a 

20 computer implemented method for managing mass customized product 

manufacturing in a factory comprises receiving an order for a customized product 
from an order requester, the order comprising base information for the customized 
product; and providing to the order requester a real-time available-to-promise date 
based on finite capacity loading of the factory. 

25 In accordance with another preferred embodiment of the present invention, a 

computer program product including computer readable logic recorded thereon for 
managing mass customized product manufacturing in a factory, comprises a 
computer-readable storage medium, and a computer program stored on the 
computer-readable storage medium. The computer program comprises instructions 

30 for receiving an order for a customized product, the order comprising base 

information for the customized product; instructions for dynamically determining 
manufacturing parameters for manufacturing the customized product based on the 
product base information; and instructions for scheduling manufacture of the 
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customized product in the factory based upon finite capacity loading of the factory 
using the manufacturing parameters. 

In accordance with another preferred embodiment of the present invention, a 
computer program product including computer readable logic recorded thereon for 
5 managing mass customized product manufacturing in a factory, comprises a 
computer-readable storage medium, and a computer program stored on the 
computer-readable storage medium. The computer program comprises instructions 
for receiving an order for a customized product from an order requester, the order 
comprising base information for the customized product; and instructions for 

10 providing to the order requester a real-time available-to-promise date based on finite 
capacity loading of the factory. 

In accordance with another preferred embodiment of the present invention, a 
method for manufacturing a product in a factory comprises receiving an order for a 
customized product, the order comprising base information for the customized 

15 product; dynamically determining manufacturing parameters for manufacturing the 
customized product based on the product base information; and scheduling 
manufacture of the customized product in the factory based upon finite capacity 
loading of the factory using the manufacturing parameters. 

In accordance with another preferred embodiment of the present invention, a 

20 system for managing mass customized product manufacturing in a factory comprises 
means for receiving an order for a customized product, the order comprising base 
information for the customized product; means for dynamically determining 
manufacturing parameters for manufacturing the customized product based on the 
product base information; and means for scheduling manufacture of the customized 

25 product in the factory based upon finite capacity loading of the factory using the 
manufacturing parameters. 

In accordance with another preferred embodiment of the present invention, a 
system for managing mass customized product manufacturing in a factory comprises 
means for receiving an order for a customized product from an order requester, the 

30 order comprising base information for the customized product; and means for 

providing to the order requester a real-time available-to-promise date based on finite 
capacity loading of the factory. 
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An advantage of a preferred embodiment of the present invention is that 
customers are provided with real-time available-to-promise dates, based on actual 
manufacturing capabilities. A direct link between the customer and the factory is 
created, which enables the customer to obtain real-time information, such as order 
5 status, stock orders, and production information. 

A further advantage of a preferred embodiment of the present invention is that 
customized goods may be produced while optimizing total manufacturing lead-time 
and cost. Mass customization capability is possible at mass production costs. 

A further advantage of a preferred embodiment of the present invention is that 
10 the architecture supports corporate intranet and Internet implementations, instead of 
the typical client-server model, thus allowing rapid system deployment. Interfaces 
such as XML facilitate the communication of specific data between existing systems. 
The Hypertext Markup Language ("HTML") world of the web may be linked with 
back-end environments capable of supporting enterprise-class applications and 
1 5 features, such as transaction support, security enforcement, and systems 
management interfaces. The architecture may also provide such benefits as 
enhanced scalability, security, and code reusability. 

A further advantage of a preferred embodiment of the present invention is that 
it may be used both by large manufacturers using traditional channels of distribution 
20 and by manufacturers that are using the Internet to sell directly to the end customer. 

A further advantage of a preferred embodiment of the present invention is that 
significantly enhanced asset utilization may be achieved through shortened 
manufacturing cycle time, increased throughput, reduced inventory levels of raw and 
finished goods, lower labor costs, and increased profitability. Increased quality, 
25 fewer returns, increased product variety, and shorten development time for new 
products are also possible. 

The foregoing has outlined rather broadly the features and technical 
advantages of the present invention in order that the detailed description of the 
invention that follows may be better understood. Additional features and advantages 
30 of the invention will be described hereinafter which form the subject of the claims of 
the invention. It should be appreciated by those skilled in the art that the conception 
and specific embodiment disclosed may be readily utilized as a basis for modifying 
or designing other structures or processes for carrying out the same purposes of the 
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present invention. It should also be realized by those skilled in the art that such 
equivalent constructions do not depart from the spirit and scope of the invention as 
set forth in the appended claims. 
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BRIEF DESCRIPTION OF THE DRAWING 

For a more complete understanding of the present invention, and the 
advantages thereof, reference is now made to the following descriptions taken in 
5 conjunction with the accompanying drawing, in which: 

FIGURE 1 is a block diagram of a typical prior art manufacturing model; 
FIGURE 2 is a block diagram of a preferred embodiment manufacturing 

model; 

FIGURE 3 is a block diagram illustrating a make-to-order manufacturing 

10 model; 

FIGURE 4 is a block diagram illustrating a make-to-forecast manufacturing 

model; 

FIGURE 5 is a flow diagram illustrating finish-to-order manufacturing; 
FIGURE 6 is a flow diagram illustrating the options engine process; 
15 FIGURE 7 is a block diagram illustrating a preferred embodiment as 

implemented in an ecommerce model; 

FIGURE 8 is a block diagram illustrating another preferred embodiment of the 
present invention; 

FIGURE 9 is a block diagram of the eCustomer module interface; 
20 FIGURE 10 is a state machine diagram illustrating the life of a promise order; 

FIGURE 1 1 is a block diagram illustrating an hMode customer model; 
FIGURE 12 is a block diagram illustrating an eMode customer model; 
FIGURES 13-15 are block diagrams illustrating customer and eCustomer 
communication protocols; 
25 FIGURE 16 is a block diagram illustrating the modes used in order booking; 

FIGURE 17 is a block diagram of the eSupplier module interface; 
FIGURE 18 is a state machine diagram illustrating the life of a delivery order; 
FIGURE 19 is a block diagram illustrating an hMode supplier model; 
FIGURE 20 is a block diagram illustrating an eMode supplier model; and 
30 FIGURES 21-23 are block diagrams illustrating supplier and eSupplier 

communication protocols. 



WO 01/73651 



PCT/US01/08771 



DETAILED DESCRIPTION 

The making and using of the presently preferred embodiments are discussed 
in detail below. It should be appreciated, however, that the present invention 
5 provides many applicable inventive concepts that can be embodied in a wide variety 
of specific contexts. The specific embodiments discussed are merely illustrative of 
specific ways to make and use the invention, and do not limit the scope of the 
invention. 

The present invention will be described with respect to preferred 
10 embodiments in a specific context, namely a distributed, Java-based software 
implementation. The invention may also be applied, however, to other systems 
utilizing other software languages, implemented on one or more computer systems. 

One aspect of the scheduling engine used in a preferred embodiment of the 
present invention is that the software is capable of running in two different modes. 
1 5 One mode is the mass customization mode and the other mode is a make to 

forecast mode. Both modes of software operation have option-based capability, and 
permit real-time communication by the customer with the factory for scheduling and 
reporting. 

In the mass customization mode products are made to order. For example, 
20 for an apparel company, a customer can custom design the jacket that they want, 
and then get a real delivery date in real-time from the factory. The product is made 
based on the options and then shipped. The entire process may be managed by a 
preferred embodiment of the present invention. For a make-to-order company, there 
is a direct one-to-one process for each order and the routing in the factory. 
25 The make to forecast mode utilizes more of an order booking system, is 

generally used in a more traditional factory. It functions somewhat like an airline 
reservation system, where the scheduling engine carefully calculates, based on a 
forecasted demand, the smallest lot size that can be made, based on real capacity, 
and then it generates a predictive schedule. Then as orders are booked, on a web 
30 site, for example, each order is being assigned its own slot in the schedule. 

In the make to forecast system, a leveling engine enhances the forecasting 
function. There will still be the concept of forecasting as is done in the prior art. 
However, a prior art system simply determines the number of units to be made 
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based on the demand for the month (e.g., make 50,000 units of product A this 
month). In contrast, in a preferred embodiment, the leveling engine determines a 
distribution of when to make certain quantities of each product during the month. For 
example, product A will be produced in 10,000 unit buckets and product B in 5,000 
5 unit buckets, which are evenly distributed throughout the month. An advantage is 
that if the demand for product A is less than was predicted, the final batches of 
product A may be canceled, the factory is not left with extra inventory because it 
already made 50,000 units in one large batch. 

The prior art manufacturing model generally assumed by major ERP and 

10 SCM vendors is shown in Figure 1. By using ERP and SCM products to optimize 
inventory levels of each point in the supply chain, manufacturing companies have 
been able to reduce inventory by 10-15%. In contrast, a preferred embodiment of 
the present invention allows the customer drive manufacturing directly as shown in 
Figure 2. Manufacturing is generally more efficient than with prior art systems, 

1 5 because the manufacturer can focus directly on filling orders, versus producing to 
meet a projected, and generally inaccurate, demand or forecast. 

For example, lead times may be reduced from the historical 5 to 10 weeks 
typical of traditional SCM technology to 3 to 5 days. The total amount of non-value- 
added activity involved with maintaining inventory and labor costs may be reduced 

20 as much as to 1/10 that of current levels. While supply chain management software 
generally only yields improvements of up to 10-15%, e-manufacturing algorithms in a 
preferred embodiment have reduced inventories and costs by 50-90%. 

Preferably, the system and method are implemented with a distributed 
component architecture, thus facilitating the integration with other software 

25 packages. These software components include an eManufacturing module 100 (with 
Options Engine module 102 or Lead-time Leveling module 108), an eCustomer 
product module 104, and an eSupplier product module 106, and are illustrated in 
Figure 3 for a make-to-order manufacturer, and in Figure 4 for a make-to-forecast 
manufacturer. Each of the software components are described in detail below. 

30 Further information on other software components may be found in U.S. Provisional 
Application No. [Attorney Docket No. 800494], filed on March 24, 2000, entitled 
METHOD AND SYSTEM FOR MANAGING AND OPTIMIZING THE 
MANUFACTURE OF CUSTOMIZED GOODS. 
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L System Overview 

One of the key components of a preferred embodiment of the present 
invention is the ability to let the customer communicate directly with the Factory. For 
5 make-to-order companies, the preferred embodiment will (1) receive order 
information (along with any option information), (2) run a simulated schedule to 
determine actual delivery date commitment based on actual capacity load in the 
factory, and (3) provide actual delivery date commitment to the customer. 

For traditional companies, the preferred embodiment takes forecasted 

1 0 demand for orders and then performs Leveling. This creates a schedule for the 
factory that achieves the smallest lot size possible based on labor availability, 
machine availability, and other factors. When a customer then goes to order a 
product, they will actually book a slot on the manufacturing schedule. This 
information is then seen on the factory floor. The Leveling algorithm will obtain the 

1 5 highest probability the high demand products will be produced very frequently while 
low volume products are produced less frequently. 

For mass customization companies, the software can create a Leveled 
schedule based on a forecast for Sub-Components. For example, assume that the 
manufacturer will sell 500 chairs next month, but the exact color of Fabric is 

20 unknown. A preferred system will create a Leveled Schedule for the base chair 
without Fabric (the same approach used for traditional companies). When an order 
gets Booked with the exact fabric, the system will schedule the based chair to be 
pulled from stock and finished to order with the exact fabric. This provides the 
perception to the customer that they received a totally custom product in a couple of 

25 days, but the reality is that some of the chair was made to forecast while the last part 
is finished-to-order. 

Figure 5 shows an implementation of a preferred embodiment system as it fits 
into a typical eCommerce model, in which sales staff and internet customers 
purchase from a standard web browser. 
30 Another preferred embodiment of the present invention is illustrated in Figure 

6, including eCommerce Web Site 120, and eManufacturing/data collection back-end 
122 with preferred embodiment software system 124 (e.g., Streamline™) at the core. 



WO 01/73651 PCT/US01/08771 

The incorporation of eCommerce will optimize existing business processes, 
automate labor-intensive steps and compress the time it takes to deliver products to 
customers. It will also radically change the sales model for direct sales companies in 
that they will change from a relatively small direct sales force, to an eCommerce 
5 model that creates thousands of potential customers that can enter orders directly. 
The sales force can redirect their efforts more towards marketing, creating new 
customers, and promotion versus, e.g., completing order forms, tracking orders, 
traveling to each existing customer. 

This model will also make companies more responsive to their customers as 

10 well as make it more convenient for their customers to do business that will increase 
repeat customers. The effect is a cost reduction, increased profits, and fewer errors 
due to computer automation of existing processes and more satisfied customers. 
Sales people can spend less time performing labor-intensive paperwork and more 
time helping customers. The capability for end-customers to get accurate delivery 

1 5 dates and to track their orders through the process is a key feature that enhances 
the customers experience. 

II. eManufacturing/Qptions Engine 

20 Process for Managing Finish-to-Order Manufacturing 

For many products, there is a base product that is manufactured in 
combination with small unique attributes that are custom. Examples are provide in 
Table 2: 



Base Product 


Options 


Table 


Finish of Wood 


Sports Jacket 


Type of Lining 


Packaged Food Product 


Label, Bottle Size 


Chair with no Arms 


Style of Arms 


Computer Chassis and 
Processor 


Hard Disk Size, Ram, etc. 


Sofa 


Material 




fable 2 
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To offer fully custom products, it is sometimes necessary to wait until all the 
attributes are specified before manufacturing is begun. The execution of this type of 
process by the Option Engine is described below. For other products, it is possible 
5 to manufacture some base of the product in advance and then place the semi- 
finished product into Work-In-Process inventory until there is a confirmed order along 
with the remaining specific attributes. 

The advantage of this approach is that it can drastically shorten 
manufacturing lead time. By waiting to begin any manufacturing until the order is 

10 placed, all manufacturing steps need to be executed for all parts of the product after 
order is placed. In contrast, if the base product is made in advance, the lead time 
only consists of the time to make or add the final component(s) of the product. The 
result is that the customer obtains the perception of receiving total custom products 
in a very short time, but the reality is that most (e.g., 80-90%) of the product was 

1 5 made in advance with only the remaining custom items added at the end. Figure 7 
shows the process step for handling Finish-To-Order Manufacturing: 

Description of Options Engine for Mass Customization 

The Options Engine is used to generate the following information dynamically: 

20 

Process Routes 

Bill Of Materials ("BOM") 

Capacity 

Labor 

25 Changeover 

Assembly Work Content 

The Options Engine processes the custom order (which is base product plus 
options), and generates the information described above for each order. The 
30 software front end stores the options selected for a specific product so that the ASP 
User Interface can display the option information. Figure 8 illustrates the flow 
diagram for the Options Engine. Table 3 below lists the information tables used for 
the base process, and their associated fields, while Table 4 illustrates the information 
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tables used for the order-based process, and their associated fields. Finally, the 
table provided in Appendix 3 demonstrates an example of using order-based 
information for the BOM, specifically the use of options to select the appropriate file 
with the cutting pattern. 



Table Name 


Table Fields 


FIOptionAvailBOM 


OptionAvailableNdx 

ChildProductNdx 

Quantity 


FIOptionAvailCapacity 


OptionAvailableNdx 

Capacity 

Time 

BaseCapacity 
LossFactor 


FIOptionAvailRoute 


OptionAvailableNdx 
workCenterNdx (Currently Missing) 
processRouteOrder (Not Needed) 


FIOptionBOM 


OptionCategoryNdx 

ChildProductNdx 

Quantity 


FlOptionCapacity 


OptionCategoryNdx 

Capacity 

Time 

BaseCapacity 
LossFactor 



Table 3 
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Table Name 


Table Fields 


fIFactoryOverrideBOM 


WorkOrderNumber 
ProductNdx 
ParentProductNdx 
Quantity 


FIFactoryOverrideCapacity 


WorkOrderNumber 

ProductNdx 

workCenterNdx 

Capacity 

Time 

ProcessRouteOrderValue 


FIFactoryOverrideProcessRoute 


WorkOrderNumber 
ProductNdx 
WorkCenterNdx 
processRouteOrder 



Table 4 



5 Determining the BOM 

The table in Appendix 3 provides an example of the typical types of 
information that is used in determining BOM components. Generally in order to keep 
the software generic, the option information is converted to a unique identifier string 
that is unique to that specific set of options. This unique set of options plus base 
1 0 productNdx is used to identify the childProduct. This data would be stored in table 
FIOptionAvailBOM using the schema shown in Table 5. 



ChildProduct 


ParentProduct 
(Base) 


OptionlDSTring 


quantity 



















Table 5 
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The OptionlDString is generated to represent the unique set of options that 
are required for the product Another table (flOptionsBOMOptions) is used to keep 
track of options that need to be considered in the Bill of Material calculations. These 
5 values selected for the option included in this table are concatenated to create the 
OptionlDString. 

When an order is placed for a specific product the following steps take place 
to determine the child or parent components for the BOM: 



10 (1 ) Reference table flOptionsBOMOptions to determine which options 

need to be considered in determining the BOM information. 

(2) Create a unique OptionslDString based on the options selected. 

(3) Reference the table FIOptionAvailBOM, and use optionslDString 
and parentProduct as the constraints in the where clause of the sequel call. 

15 This will then return the childProduct and quantity that should be used in the 

BOM. Since the customer will be purchasing an end-product, this will 
generally always start out as the parentProduct 

(4) Once all the children have been generated for the parentProduct, 
go back to Step (1) and use the childProduct(s) just created as the 

20 parentProduct. This process should continue until all the childProducts are 

created. 



Determining Routing 

The first step establishes all the work centers in the system. For each work 
25 Center, the operationSequence is organized in a way that describes the basic 
sequence in which work centers will be used for all products. There may be some 
cases where the sequence may change, but for over 90% of the products the basic 
sequence will be the same. 

An example of a series of work centers would be as shown in Table 6: 
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Work Center 


Operation 
Sequence 


Kitting of Materials 


10 


Cutting Materials 


20 


Printing on Materials 


30 


Secondary Printing on Materials 


40 


Sewing of Materials 


50 


Inspection and Packing 


60 



Table 6 



For a given product with NO Options considered, the basic route information 
can be determined from the table fLFactoryProcessRoute. For an example product, 
the basic routing defined may look as shown in Table 7: 



ProductNdx 


WorkCenterName 


processRouteOrder 


ABC 


Inspection and 
Packing 


0 


ABC 


Sewing of Materials 


1 



Table 7 



This processRoute definition means that for products ABC, the base routing is 
to first go to sewing of materials, and the second step (in this case the last) would be 
inspection and packaging. 

Next, the order-based route is determined based on options. As an example, 
assume that an order is placed for product ABC, and it has an option for Printing. 
The Order Number is 12345. The table called flOptionAssignment provides the 
optionAvailable for product ABC . The table called AOptionAvailRoute provides 
information that describes what routes will have to be added based on the option 
selected. In the example above, assume that product ABC has the option called 
Printing that is described in AOptionAvailRoute as shown in Table 8: 
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OotionAvailable 


WorkCenterName 


OptionAvailable 
(Printing) 


Printing on Materials 



Table 8 



Based on this information, the new route for order number 1 2345 may be 
5 created and this information placed in fIFactoryOverrideProcessRoute as shown in 
Table 9: 



Order Number 


ProductNdx 


WorkCenterName 


processRouteOrder 


12345 


ABC 


Inspection and Packing 


0 


12345 


ABC 


Sewing of Materials 


1 


12345 


ABC 


Printing on Materials 


2 



Table 9 



The system can determine the processRouteOrder based on the Operation 
Sequence defined for each work center The processRoute Order value is 
recalculated once all the option information is specified. 

Assume that another order is placed for product ABC. The Order Number is 
1 5 9999, and the options include the following: 

Printing on materials 
Secondary Printing on Materials 

20 Based on these options, fIFactoryOverrideProcessRoute includes the 

following information for Order Number 9999 as shown in Table 10. Note that the 
processRouteOrder is 3 in this case, which is different from the previous example. 

25 
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Order Number 


ProductNdx 


WorkCenterName 


processRouteOrder 


9999 


ABC 


Inspection and Packing 


0 


9999 


ABC 


Sewing of Materials 


1 


9999 


ABC 


Secondary Printing on 
Materials 


2 


9999 


ABC 


Printing on Materials 


3 



- Table 10 



Finally, the other order-based information using the route may be determined. 
5 Once the Process Route for the order is established, the following tables can be 
populated: 

FIFactoryOverrideCapacity 
FIFactoryOvenrideLabor 
1 0 FIFactoryOverrideChangeover 
FIFactoryOverrideWorkCenter 

For each of these areas, the tables shown in Table 1 1 from flOptionAvail 
provide the data that is needed for populating the information: 

15 
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Table Name 


Table Fields 


FIOptionAvailBOM 


OptionAvailableNdx 

ChildProductNdx 

Quantity 


FIOptionAvailCapacity 


OptionAvailableNdx 

Capacity 

Time 

BaseCapacity 
LossFactor 


FIOptionAvailRoute 


OptionAvailableNdx 
workCenterNdx (Currently Missing) 
processRouteOrder (Not Needed) 


FlOptionCapacity 


OptionAvailableNdx 

Capacity 

Time 

BaseCapacity 
LossFactor 



Table 11 



As seen above, these tables. reference OptionAvailableNdx, which points to 
5 both an option and a productNdx. Using this method, once the base product and 
options are known, the information can be easily calculated. 

III. eCustomer Product Module 

10 The eCustomer product module functions as an add-on to the core software, 

allowing customer-to-factory integration. The eCustomer product module provides 
an interface to a customer entity, as shown in Figure 9. 

The customer entity can issue a request to the eCustomer product module for 
the manufacture of a product. The eCustomer product module responds with 

1 5 promise order information containing the promise date. The eCustomer product 
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; module is also able to provide status of products scheduled for manufacture in the 
system. 

A customer can be an external customer (end consumer) or it can be an 
internal customer within the company (company's distribution center). The 
5 eCustomer product module gives users tightly coupled integration with their 

customers. Both the factory and the customer benefit from the increased visibility 
into each other's operations. 

Authentication of customers may be done by a security service, which could 
run as a Distributed Services Engine Plug-in. That way all subsystems in the 
10 software could benefit from the security service. With respect to securing a 

communications channel between the browser and the web server on the software 
platform, Secure Socket Layers ("SSL") and possibly digital certificates may be used. 
This protocol provides an encrypted channel between the web server and the 
browser and the ability to identify the user. This technology is widely supported by 
1 5 web server and browser vendors. This technology easily interfaces with firewall 
technology as well. 

Available to Promise (Promise Order) for Make-To-Order Companies 
A promise order is an order related to a customer, and is a commitment that 
20 the factory will manufacture and ship the order on a promised date. Some of the 
types of information that a promised order may contain are product type, quantity, 
purchase order number, due date and point of contact. 

An Available-To-Promise date (e.g. exact delivery date) may be provided to 
the end customer. This date may vary as work load changes, and items such as 
25 minimum allowable lead time (e.g. 3 weeks), safety factors, time for shipping, etc., 
are specified in the system. The release date may be automatically specified for 
orders on the shop floor. The delivery date is calculated based on actual lead-time 
given current physical constraints. Constraints are considered throughout the 
manufacturing process when determining the release date. 

30 

OrderBookina Concept 

Order booking is a subsystem in the eCustomer product module. This 
subsystem is responsible for getting obtaining the information needed when a 
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particular promise order can be completed and shipped. The Orderbook'mg 
subsystem has different working modes depending on the options driving how the 
factory is managed. More details on this subsystem are presented in a following 
section. 

5 

XML Page Rendering 

The eCustomer product module renders all pages in XML so that if the 
customer can embed the results into an HTML page. This allows maximum flexibility 
in that humans can read these pages with XML capable browsers, while the System 
10 can simultaneously allow machine communications with support for XML. 



High-level Responsibilities 

The eCustomer product module's has several specific responsibilities. The 
first is that it must keep a list of all active customers and their associated information. 
1 5 The types of information that the eCustomer product module must keep per 
customer are: 

Usemames and passwords (Security Discussed in a separate document) 
Active Purchase Orders 
20 Point of Contacts 

Typical Product Order Templates 
Shipping Preferences 

The eCustomer product module manages all of the factory conversations with 
25 the customer entity. There are several different types of customer-to-factory 
conversations as listed below: 



Accepting requests for manufacture of a product and a promised order. 
Providing promise data information. 
30 Accepting commitments/rollbacks on promise orders 

Providing alerting when promise dates can't be met 
Providing product option and selection information 
Providing current product status information. 
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The conversation extends through the life of the promised order. The 
promised order life cycle spans several states such as: proposed, accepted, 
rejected, confirmed, aborted, inManufacture, inShipment to fulfilled. The eCustomer 
5 product module manages all promised orders during their lifetime. This module also 
supports a group of outpipes that can be used to alert the customer point of contact 
of late or cancelled orders. A second outpipe implementation can be used for 
alerting the factory point of contact for canceled promised orders from the customer 
side. More details on outpipes are presented in a following section. 

0 

Promise Order State Machine 

The life of a promise order can be described using a state machine. The 
specific states that a promise order may fall into are described below: 



1 5 Proposed - By customer representative when asking for promise order. 

Accepted -By factory when giving promise order. 

Rejected - By factory when declining due to capacity problem. 

Confirmed - By customer representative if accepting the promise order. 

Aborted- By customer representative by aborted the promise order. 
20 InManufacture - Factory is manufacturing the promise order. 

InShipment^ Left Customer and in transit to customer 

Fulfilled - Received and approved by customer. - 

The state transitions are shown in the state machine diagram in Figure 10. 
25 The state machine outlines a successful promise order as well as showing cases 
where a promise order can end in failure. The promise order states can execute 
over a period of a couple of days to a couple of weeks. The eCustomer product 
module is designed to manage the lifecycle of the promise order for the factory. 



30 Workflow and Roles 

There are four different human workflows each containing a set of ASP/JSP 
screens, as listed below: 
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Factory Floor 
Accounts Receivable 
Shipping 

Overall Administrative Management of eCustomer product module. 

5 

The first workflow is for the personnel on the factory floor. This workflow is 
composed of ASP/JSP screens and reports allow the factory to manage incoming 
orders from the customer entity. The types of functionality provided here are 
described below: 

10 

ASP/JSP screens to view booked orders by product, customer or timeline. 
ASP/JSP wizards to add, modify and delete customer order templates (repeat 
orders). 

ASP/JSP form to abort (cancel) a promised order. 
15 ASP/JSP form to signal that a promised order is late. 

The workflow for the accounts receivable also provides the ability to trigger 
invoices to the customer. The types of reports and wizards are shown below: 

20 ASP/JSP wizards to add, modify and delete customer entities. 

ASP/JSP reports on customer order activity. 

ASP/JSP-reports to view booked orders by product, customer and timeline. 
ASP/JSP form to abort a promised order. 



25 The workflow for the shipping is designed to give the factory shipping 

department the ability to synchronize the shipping of finished products to the 
customer. Examples of ASP/JSP screens are: 



ASP/JSP reports showing booked orders status. 
30 ASP/JSP reports showing booked orders by customer. 

ASP/JSP reports showing shipping preference and point of contact 
information 
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The workflow for the general administration is designed to give administrators 
and deployment teams configuring the system the ability to easily configure the 
product Examples of ASP/JSP screens are: 

5 ASP/JSP wizards to enable/disable outpipes. 

ASP/JSP wizards to set service provider connection strings for the enabled 
outpipes. 

ASP/JSP wizards to defineihe type of OrderBooking service provider to use. 
ASP/JSP wizards to define the Inter-Business XML Dialog to use. 
10 ASP/JSP wizard to configure general options and system parameters. 



Database Tables 

1 5 Appendix 1 provides names and create scripts for the tables used to 

implement the eCustomer product module. 

Promised Order Influences on Factory Customer Work Orders 
Flags are used to indicate whether a factory promised order and its 
20 corresponding work orders have all the stock in place to be manufactured. Several 
flags associated with each product in the factory collectively describe the physical 
capability for the manufacture of the work order. The flags are listed below: 

Flag A - All parts are already in stock. 
25 Flag B - All parts are not in stock but are confirmed delivery orders on 

proposed due date! 

Flag C - All parts not in stock but are confirmed delivery orders on Customer 
alternate date. 

Flag D - Not in stock and unable to confirm a delivery order! 

30 

These flags indicate whether normal manufacturing can continue. As part of 
this process, Gantt charts showing the customer manufacture of the part, shipping 
out, transport, receiving in, product manufacture in the factory, may be generated. 
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Popup Gantt charts may also show what is confirmed and what is not. Note that 
delivery orders should go through the normal set of states. 

hMode Model 

5 In the hMode model there is a system in the factory with an eCustomer 

product module. In this mode the human initiates requests for promise orders. The 
eCustomer module after authentication, will accept the request for manufacture XML 
document and feed it to the OrderBooking subsystem. 

The OrderBooking subsystem will determine the promise date and return the 

10 information back to the eCustomer product module, which will forward the response 
to the human point of contact at the customer facility. At some time later the human 
point of contact at the facility can commit to the promise order or abort it to cancel 
the order. Not doing either automatically results in abort after a specified amount of 
time. Aborting the promise date has the effect of a rollback in the factory schedule. 

1 5 Specific out-pipes in eCustomer allow it to send data to the outside world when 
specific events like this occur during this transaction. Figure 1 1 illustrates the 
hMode model. 

This model provides business-to-business eCommerce where the eCustomer 
product module in conjunction with the core system in the factory is communicating 
20 with a human point of contact at the customer facility. Note that the human at the 
customer's facility can log into the eCustomer product module in the factory at 
anytime to view the status of promise orders. 

eMode Model 

25 The eMode model provides business-to-business eCommerce where the 

eCustomer module in conjunction with the core system in the factory is 
communicating with another eCommerce system at the customer facility. If the 
customer facility contains a core system then it should be configured with an 
eSupplier prdduct module. The eSupplier product module is specifically designed to 

30 communicate natively with the eCustomer product module. The request for 
manufacture of a promise order information is electronically sent between the 
customer facility to the eCustomer product module. In a normal situation the promise 
order life cycle proceeds from: proposed, accepted, confirmed, inManufacture, 
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inShipment to fulfilled in an automated fashion between these two systems. Humans 
may be required to update the status of these promise orders as they move through 
their life cycle, but the process is automated where possible. Figure 12 illustrates 
the eMode model. 

5 This eCommerce automation process compresses the time needed to move 

finished products through to the customer as well as squeeze out any inefficiencies 
that would exist if humans were driving the process. An Orderbooking subsystem 
within the eCustomer product module is used in determining the promise date for the 
customer. Details on the OrderBooking subsystem are provided in following 
10 sections. 

The eCustomer product module can simultaneously support customers in 
both hMode and eMode. 

Inter-Business XML Dialogs 
15 This section describes the XML dialogs enabling this collaborative process 

between the eCustomer product module and the customer. A preferred embodiment 
supports a native XML based dialog as well as other industry standard dialogs. The 
XML based dialogs supported by the eCustomer product module include those listed 
below: 

20 

; Factory Logic Native XML based dialog 
RossettaNet 

Open Applications Group 
BizTalk Public Domain Schemas 

25 

The eCustomer product module's native interface is described below. The 
software provides a management mechanism for electronically facilitating the 
promise order proposal, acceptance and confirmation. Referring to Figure 13, the 
customer proposes promise orders. Promise orders that are proposed are either 
30 accepted or rejected by the factory. When a factory accepts a promise order the 
customer can confirm it or abort. If the customer confirms then the factory will 
manage the promise order through the manufacturing and shipping. 
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The messaging used in this workflow uses XML based documents. The XML 
based documents for each of the messages generated above are shown below. The 
first is the promise order proposal received from the customer 

<?xml version- w 1 .0 V ?> 

<!DOCTYPE OrderRequest SYSTEM 7Properties/OrderRequest.dtd"> 
<OrderRequest > 

<transactionNumber> </transactionNumber> 
<orderNumber> </ordertslumber> 
<product> 

<code> </code> 
<quantity> </quantity> 
<options> 

</options> 
</product> 
</OrderRequest> 

The next XML based document is returned from the factory to the customer. 
It contains information indicating if the factory accepted or rejected the promise 
order. Once this occurs the customer will confirm or abort the promise order. 

<?xml version- '1 .0 M ?> 

<!DOCTYPE OrderResponse SYSTEM TProperties/OrderResponse.dtd^ 
<OrderResponse> 

transaction Number> </transactionNumber> 

<orderNumber> </orderNumber> 

<status> </status> 
<promiseDate> </promiseDate> 
</OrderResponse> 

If the eCustomer product module accepts the promise order then the 
customer entity must confirm the order. 
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<?xml version="1 .0 W ?> 
<!DOCTYPE OrderConfirmation SYSTEM 
M /Properties/OrderConfinmation.cltcr> 
5 <OrderConfirmation> 

<transactionNumber> </transactionNumber> 
<ordertslumber> </orderNumber> 
<conformationStatus> </confirmationStatus> 
</OrderConfirmation> 

10 

These XML based documents are used to implement this conversation 
between the factory and the customer. Additionally a second possible conversation 
between the customer and factory involves the query of a promise order. Figure 14 
illustrates this conversation. 
15 The XML document shown below is used by the customer to query the factory 

with respect to the status of a promise order 

<?xml version= M 1 .0 W ?> 
<!DOCTYPE OrderStatusRequest SYSTEM 
20 7Properties/OrderStatusRequest.dtd D > 
<OrderStatusRequest > 

transaction Number> </transactionMumber> 

<orderNumber> </orderNumber> 
</OrderStatusRequest> 

25 

The next XML based document is used by the factory to provide status 
information on a promise order to the customer. 

<?xml version="1.0 M ?> 
30 <!DOCTYPE OrderStatusResponse SYSTEM 

7Properties/OrderStatusResponse.dtd n > 
<OrderStatusResponse> 

<transactionNumber> </transactionNumber> 
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<orderNumber> </orderNumber> 

<status> </status> 
<promiseDate> </promiseDate> 
</OrderStatusResponse> 

5 

i 

The third conversation between the customer and factory involves the 
notification of aborted promise order. Figure 15 illustrates this two way conversation. 

The XML document shown below is used by the customer/factory to notify the 
factory/customer with respect to the abort of a promise order 

10 

<?xml version="1.0 w ?> 
<!DOCTYPE OrderCancelRequest SYSTEM 
w /Properties/OrderCancelRequest.dtd"> 
OrderCancelRequest > 
1 5 <transactionNumber> </transactionNumber> 

<orderNumber> </orderNumber> 
</OrderCancelRequest> 



The next XML based document is used by the factory/customer to 
20 acknowledge the aborted promise order. 

<?xm( version=*1.0 n ?> 

<!DOCTYPE OrderCancelResponse SYSTEM 
7Properties/OrderCancelResponse.dtd"> 
25 <OrderResponse> 

<transactionNumber> </transactionNumber> 
<orderNumber> </orderNumber> 
<status> </status> 
</OrderCancelResponse> 

30 

The other party must then send an XML document to confirm that the promise 
order is to be cancelled. 
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<?xml version="1.0 ,, ?> 

<!DOCTYPE OrderCancelConfirmation SYSTEM 
0 /Properties/OrderCancelConfirmation.dtcl ,, > 

<OrderCancelConfirmation> 

<transactionNumber> </transactionNumber> 
<orderNumber> </orderNumber> 
<cancelConformationStatus> </cancelConfirmationStatus> 

</OrderCancelConfirmation> 

The above documents precisely define the interface to the eCustomer product 
module. If the subsystem at the customer site implements this interface, then the 
eCustomer product module should be able to readily integrate with it. The 
specifications for RossetaNet, Biztalk, the Open Application Group, or other software 
languages are implemented in a similar fashion. 

If the eCustomer receives an erroneous XML dialog it generates an XML Error 
Response and sends it back to the server. This dialog pulls its error messages from 
the fILanguage database for internationalization. The actual dialog is: 

<?xml version="1.0 n ?> 

<!DOCTYPE Error SYSTEM 7Properties/OrderCanceIConfirmation.dtd"> 
<Error> 

<transactionNumber> </transactionNumber> 
<errorCode> </errorCode> 
<errorString> </errorString> 
</Error> 

Where the errorCode is the look up code in the database and errorString is 
the optional error string to be attached to the XML document 

Promise Orders and Multiple Product IP's 

The promise order can contain multiple product orders within it The customer 
can order more than one product per product configuration. The promise order 
request contains the promise order work order number. Each product will contain a 
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product ID which can be used to identify it within the overall work order. An example 
is promise order W030568 which contains products A, B and C. In this example the 
eManufacturing system will schedule the elements W030568-1, W030568-2 and 
W030568-3. The customer receives a promise date which is the longest lead time 
5 for all three of the products. 

OrderBookina and its Service Providers 

Ordering booking essentially relates to reserving manufacturing capacity. 

This section describes the specific programming interface customers use to book 
1 0 orders. An Actor design pattern inside the OrderBooking subsystem is used. The 

reservation request is made by the abstracted order booking API subsystem. The 

reservation fulfillment for the request is generated by one of the service providers. 

There are 3 service providers available to use and their selection is determined by 

how the factory is being managed, as shown in Figure 16. 
15 There are 3 basic modes the factory can operate in and based on this the 

appropriate service provider is selected. These modes are listed below: 



(1) Make-to-Forecast Factory in 1:1 Internal Work Order Mode 

(2) Make-to-Forecast Factory in Leveled Internal Work Order Mode 
20 (3) Make-to-Order Factory with use of Options Engine 



Under mode 1, the system will take in forecasted work orders and schedule 
them on a 1:1 basis. Under mode 2, forecasted orders are passed through a 
Leveling Algorithm to create internal work orders which are then scheduled for 
25 production. 

Under mode 3, the schedule receives an order and dynamically creates 
specific Process Route information, Bill of Material Information, capacity, 
changeover, labor, etc. 

There is one service provider specifically designed to be used depending on 
30 the factory is being managed. The service provider generally always returns a 
promise date to the customer but how it derives that promise date varies on the 
management of the factory. 
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OrderBookina Benefits 

This subsystem allows users to book manufacturing capacity in such a way as 
they might do when booking an airline ticket when interacting with an airline 
reservation system. The benefits of the customer booking orders are: 

5 

, (1) Establish when their product will be made. 

(2) Reserve manufacturing capacity (or products). 

(3) Shorter lead-time for delivery. 

10 The manufacturing facility also benefits from the order booking subsystem. 

The benefits to the factory are: 

(1 ) Lower stock level with higher customer service.. 

(2) Direct visibility by factory workers into exact customer demand. 

15 (3) Give prospect visibility into when the product they are seeking will be 

manufactured. 

(4) Factory gets visibility with what customer is buying making it more 
customer driven. 

(5) Allows factory to cancel orders not booked - customers do not want 

20 

Qrd er Booking Backend Java Business Logic 

The OrderBooking subsystem has foreign keys to the fIFactoryScheduleRpt 
table so these references should be deleted before creating a new schedule. In 
25 addition, the booked finished date should be recalculated. Also, an outpipe 

(message to the person booking the system if their product will be late) may need to 
be triggered if there are promise orders that cannot be met. 

Outpipes within the eCustomer Module 
30 Out-pipes can be enabled or disabled by setting an option within the 

application at the point of deployment The first out-pipe involves sending data to the 
outside world when a promised order has been completed. An example of this is 
configuring the out-pipe to be turned on with the email notification service provider. 
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When the promise order completion date is sent out the out-pipe would generate an 
email to shipping about this particular competed promise order. 

A second out-pipe example is to the accounts receivable department This 
out-pipe sends information after the booking of a customer order. This allows 
5 accounts receivable the ability to start the invoice process for the customer. This 
outpipe might be configured to be turned on using a fax service provider. When the 
eCustomer module booked a customer order then data would be sent out this 
outpipe. The out-pipe would send a fax to the point of contact in the accounts 
receivable department 

10 Another outpipe is to send data out when a promise order is late. An example 

of how it might be configured at deployment is to configure the out-pipe with the 
email service provider. When a promise order is determined to be late the out-pipe 
would send the email to shipping giving them visibility into the problem. They might 
be able put the promised order into a rush shipment in an attempt to get the promise 

1 5 order delivered on time. 

These out-pipes can be turned on or off at the point of deployment. In 
addition they can be configured to use any of the out-pipe service providers. 



AppConfig Parameters 
20 A family of application configuration parameters may be implemented for this 

subsystem. The tags and values are listed in Table 12: 



parameterGroup 


parameterGroup 


value 


default 


"eCustomer^ 


"startTime" 


hour/minute 


00:00 


"eCustomer" 


"stopTime" 


hour/minute 


23:59 



Table 12 

25 

These parameters should be defined for the eCustomer product, or the 
defaults are assumed by this service. 



30 
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IV. eSupplier Product Module 

The eSupplier product module is functions as an add-on to the core software, 
allowing factory-to-supplier integration. The eSupplier product module provides an 
5 interface to suppliers delivery order information, as shown in Figure 17. 

If the supplier has a similar system installed, the eSupplier module provides 
the eCommerce integration between the factory's system and the supplier. The 
eSupplier module can operate on one of two modes, which are: 

10 1 . hMode - In this mode the eSupplier module interfaces with a human 

at the supplier facility. 

2. eMode - The eSupplier module interfaces with an eCommerce 
system at the supplier facility. 

1 5 Both modes are described below. The eSupplier product module is able to 

support suppliers operating in both modes simultaneously. The eSupplier product is 
designed to give users tightly coupled integration with their raw material suppliers. 
Both the factory and the raw material supplier benefit from the increased visibility into 
each other's operations. 

20 

Delivery Order Concept 

A Delivery order is an order from the factory to the supplier. The Delivery 
order request contains information such as product type, quantity, and purchase 
order number, due date and point of contact. Preferably, this is not meant to replace 
25 the traditional purchase order that is issued by the purchasing department within an 
organization. 

Dual HTML /XML Page Rendering 

The eSupplier product module renders all pages with support for both hMode 
30 and eMode. These pages support both modes simultaneously since they are 

rendered with both HTML and XML This allows humans using normal browsers the 
ability to read these pages while simultaneously allowing machine to communicate 
with the support for XML. 
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High-level Responsibilities 

The eSupplier product module has several responsibilities. The types of 
information that the eSupplier product module keeps per customer are: 

5 

Mode of operation: hMode or eMode 
Usemames and passwords 
Active Purchase Orders 
Point of Contacts 
1 0 Typical Delivery Order Templates 

Shipping Preferences 

The eSupplier product module manages all of the factory conversations with 
the supplier. There are several different types of supplier-to-factory conversations as 
15 listed below: 

Requests for delivery order. 

Accepting promise date information for the delivery order. 
Providing alerting when promise dates can't be met for delivery orders 
20 Providing product option and selection information 

Checking delivery order status information. 

Specific responsibilities of the eSupplier product module are: 

25 

The eSupplier product module integrates the factory's system with its 
suppliers. 

It supports suppliers in both hMode and eMode simultaneously. 
It communicates using XML documents over the SHTTP protocol. 
30 It alerts the factory scheduler if the supplier aborts or declares that a delivery 

order will be late. 
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Delivery Order State Machine 

The life of a delivery order can be described using a state machine. The 
specific states that a delivery order may fall into are described below: 

Proposed - By factory scheduler when gold schedule generated 
Accepted - Supplier accepts proposed delivery order. 
Rejected - Supplier rejected proposed delivery order. 
Confirmed - Factory scheduler commits to supplier on delivery order received. 
Aborts - One entity cancels the delivery order (effectively rollback) 
InManufacture - Currently being manufactured by the supplier. 
InShipment - Left supplier and in transit to customer 
Fulfilled- Received and approved by customer. 

The state transitions are shown in the state machine diagram in Figure 18. 
The state machine outlines a successful delivery order as well as showing cases 
where a delivery order can end in failure. The delivery order states can execute over 
a period of a couple of days to a couple of weeks. The eSupplier product module is 
designed to manage the lifecycle of the delivery order for the factory. 

Workflow and Roles 

There are four different human workflows each containing a set of ASP/JSP 
screens, as listed below: 

Factory Floor 
Accounts Payable 
Receiving 

Overall Administrative Management of eSupplier product module. 

The first workflow is for the personnel on the factory floor. This workflow is 
composed of ASP/JSP screens and reports allow the factory to manage incoming 
orders from the supplier entity. The types of functionality provided here are 
described below: 
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ASP/JSP reports to view delivery orders by product, supplier or timeline. 
ASP/JSP reports to view delivery orders by proposed, confirmed and other 
state values. 

ASP/JSP wizards to add, modify and delete supplier order templates (repeat 
5 orders). 

ASP/JSP form to abort a delivery order. 
ASP/JSP form to signal that a delivery order is late. 

The workflow for the accounts payable also provide the ability to trigger 
10 invoices to the supplier. The types of reports and wizards are shown below: 

ASP/JSP wizards to add, modify and delete supplier entities. 
ASP/JSP reports to view delivery orders by proposed, confirmed and other 
state values. 

1 5 ASP/JSP reports on supplier delivery order activity. 

ASP/JSP reports to view booked orders by product, supplier and timeline. 

ASP/JSP form to abort a delivery order. 

ASP/JSP reports to view delivery orders performance history. 

20 The workflow for the receiving department is designed to give the factory 

receiving function the ability to synchronize the receiving of raw materials from its 
suppliers. Examples of ASP/JSP screens are:. 

ASP/JSP reports showing delivery order status. 
25 ASP/JSP reports showing delivery order by supplier. 

ASP/JSP reports showing shipping preference and point of contact 
information 

ASP/JSP reports showing delivery order priority based on factory floor 
schedules. 

30 

The workflow for the general administration is designed to give administrators 
and deployment teams configuring the system the ability to easily configure the 
product. Examples of ASP/JSP screens are: 
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ASP/JSP wizards to enable/disable outpipes. 

ASP/JSP wizards to set service provider connection strings for the enabled 
outpipes. 

ASP/JSP wizards to define the Inter-Business XML Dialog to use. 
5 ASP/JSP wizard to configure general options and system parameters. 

Delivery Orders versus Purchase Orders 

The person in the factory initiating delivery orders is the scheduler. The 
schedule generated by the scheduler along with the raw material inventory 

10 effectively determines the parts needed to be ordered. When a "gold" schedule is 
saved, the scheduler can determine what delivery orders are needed based on this 
"gold" schedule and the raw material inventory. For a delivery order to be requested 
a purchase order number is required. This is generated from the purchasing 
department. Therefore purchasing must have visibility into proposed delivery orders 

1 5 from the factory scheduler. It must also have visibility into confirmed delivery orders 
the supplier has committed to. 

Database Tables 

Appendix 2 provides names and create scripts for the tables used to 
20 implement the eSupplier product module. 

^ Delivery Order Influences on Factory Customer Work Orders 

Flags are used to indicate whether a product can be made and whether a 
factory customer work order has all the stock in place to be manufactured. Several 
25 flags associated with each product in the factory collectively describe the physical 
capability for manufacturing. The flags are listed below: 

Flag A - All parts are already in stock. 

Flag B - All parts are not in stock but are confirmed delivery orders on 
30 proposed due date! 

Flag C - All parts are not in stock but are confirmed delivery orders on supplier 
alternate date 

Flag D - Not in stock and unable to confirm a delivery order! 
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These flags indicate whether normal manufacturing can continue. As part of 
this process, Gantt charts showing phases, such as the supplier manufacture of the 
part, shipping, transport, receiving and the product manufacturing, may be 
5 generated. Pop-ups on the Gantt charts may also show what is confirmed and what 
is not. 

hMode Model - 

In the hMode model there is a system in the factory but not in the supplier 
10 facility. In this mode the system initiates delivery orders when the factory scheduler 
generates a "gold" schedule. The eSupplier product can send emails or page the 
respective supplier point of contact using outpipes and the Alerting service. Once 
notified, the supplier point of contact logs onto the factory's system to accept or 
decline the delivery orders. If the supplier accepts the delivery orders the eSupplier 
15 service will alert the factory representative so that they can confirm the delivery order 
in which case the eSupplier system can alert the supplier of this confirmation. 

This model provides business-to-business eCommerce where the system in 
the factory is communicating with a human representative of the raw materials 
supplier facility. The raw materials supplier can log into the system in the factory at 
20 anytime to view confirmed delivery orders and can post late or canceled delivery 
orders. 

eMode Model 

The eMode model provides business-to-business eCommerce where the 
25 system in the factory is communicating with a similar system located in the raw 
materials supplier facility. The delivery order information is electronically sent 
between the factory and supplier. The eSupplier product in the factory communicates 
with the system in the raw materials supplier. The eCustomer product module is the 
subsystem entity that is able to communicate with the eSupplier product in the 
30 factory. The two entities communicate using XML based documents over SHTTP. 
The delivery order lifecycle proceeds from proposed, accepted, confirmed, 
inManufacture, inShipment to fullfilled in an automated fashion between these two 
systems. The factory scheduler is able to view reports showing the latest state of any 
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delivery orders. Human intervention may be required to update the status of these 
promise orders as they move through their life cycle but the process is automated 
where possible. 

This eCommerce automation process compresses the time needed to move 
5 parts and products through to the customer as well as squeeze out any inefficiencies 
that would exist where humans were driving the process. In this mode the confirmed 
delivery orders go into the raw material suppliers system as customer orders. The 
Orderbooking subsystem within the eCustomer product module is used to derive the 
promise date for the delivery order. The factory scheduler and reports show the 
1 0 constant state of the delivery orders. 

Inter-Business XML Dialogs 

This section describes the XML based dialogs between the eSupplier product 
module and the raw material supplier. A preferred embodiment supports a native 
15 XML based dialog as well as other industry standard dialogs. The XML based 
dialogs supported by the eSupplier product module include those listed below: 

Factory Logic Native XML based dialog 
RossettaNet 
20 Open Applications Group 

BizTalk Public Domain Schemas 

The eSupplier product module's native interface is described below. The 
software provides a management mechanism for electronically facilitating the 
25 delivery order proposal, acceptance and confirmation. Referring to Figure 21 , the 
factory scheduler proposes delivery orders whenever a gold schedule is generated. 
When a supplier accepts a delivery order it moves to the accepted state. After this 
the factory scheduler must confirm the acceptance. 

30 ■ The messaging used in this workflow uses XML based documents. The XML 

based documents for each of the messages generated above are shown below. The 
first is the delivery order proposal: 
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<?xmi version="1 .0*?> 

<!D0GTYPE OrderRequest SYSTEM TProperties/OrderRequestdtd^ 
OrderRequest > 

<transactionNumber> </transactionNumber> 
5 <orderNumber> </orderNumber> 

<product> 

<cx)de> </code> 
<quantity> </quantity> 
<options> 

10 

</options> 
</product> 
</OrderRequest> 

1 5 The next XML based document is returned from the raw material supplier to 

factory and it contains information indicating if the raw material supplier accepted or 
rejected the delivery order. Once the response occurs the factory will confirm or 
abort the delivery order. 

20 <?xml version=*1 .0 M ?> 

<!DOCTYPE OrderResponse SYSTEM 7Properties/OrderResponse.dtd M > 
<OrderResponse> 

<transactionNumber> </transactionNumber> 
<orderNumber> </orderNumber> 
25 <status> </status> 

<promiseDate> </promiseDate> 
</OrderResponse> 

30 

If the eSupplier product module accepts the promise order then the customer 
entity must confirm the order. 
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<?xml version= u 1.0"?> 
<!DOCTYPE OrderConfirmation SYSTEM 
"/Properties/OrderConfirmation.dtd^ 
<OrderConfirmation> 
5 <transactionNumber> </transactionNumber> 

<orderNumber> </orderNumber> 
<conformationStatus> </confirmationStatus> 
</OrderConfirmation> 

These XML based documents are used to implement this conversation 
between the factory and the raw material supplier. 

Additionally the factory can query the raw material supplier on the status of 
delivery order. Figure 22 illustrates this conversation. 

The XML document shown below is used by the factory to query the raw 
material supplier with respect to the status of a delivery order. 

<?xml version="1.0 w ?> 
<!DOCTYPE OrderStatusRequest SYSTEM 
"/Properties/OrderStatusRequest.dtd n > 
20 OrderStatusRequest > 

<transactionNumber> </transactionNumber> 
<orderNumber> </orderNumber> 
</OrderStatusRequest> 

25 The next XML based document is used by the raw material supplier to provide 

status information on a delivery order to the factory. 

<?xml vereion="1.0"?> 

<!DOCTYPE OrderStatusResponse SYSTEM 
30 7Properties/OrderStatusResponse.dtd M > 
Orders tatusResponse> 

<transactionNumber> </transactionNumber> 

<orderNumber> </orderNumber> 



10 



15 
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<status> </status> 
<promiseDate> </promiseDate> 
</OrderStatusResponse> 

5 Finally the factory or the supplier can cancel a delivery order. Figure 23 

illustrates this cancellation. 

The XML document below is used by either the factory or the raw material 
supplier to cancel a delivery order that had previously been issued to the raw 
material supplier. The party canceling the delivery order or the 1st party sends this 
10 XM L document to the second party: 

<?xml version= w 1 .0 n ?> 
<!DOCTYPE OrderCancelRequest SYSTEM 
°/Properties/OrderCancelRequest.dtd"> 
15 ' OrderCancelRequest > 

<transactionNumber> </transactionNumber> 
<orderNumber> </orderNumber> 
</OrderCancelRequest> 

20 The next XML based document is used by the 2 nd party to acknowledge the 

cancellation of the delivery order. 

<?xml version= n 1.0"?> 

<!DOCTYPE OrderCancelResponse SYSTEM 
25 7Properties/OrderCancelResponse.dtd M > 
<OrderResponse> 

<transactionNumber> </transactionNumber> 
<orderNumber> </orderNumber> 
<status> </status> 
30 </OrderCancelResponse> 
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The other 1 st party must then send an XML document to confirm that the 
promise order is to be cancelled. 

<?xml version="1.0"?> 
5 <!DOCTYPE OrderCancelConfirmation SYSTEM 

VProperBes/OrderCancelConfirmation.dtd^ 
<OrderCancelConfirmation> 

<transactionNumber> </transactionNumber> 
<orderNumber> </orderNumber> 
1 0 <cancelConformationStatus> </cancelConfirmationStatus> 

</OrderCancelConfirmation> 

The above documents precisely define the interface to the eSupplier product 
module. If the subsystem at the supplier site implements this interface, then the 
15 eSupplier module should be able to readily integrate with it. The specifications for 
RossetaNet, Biztalk, the Open Application Group, or other software languages are 
implemented in a similar fashion. 

Outoipes within the eSupplier Module 

20 Out-pipes can be enabled or disabled by setting a flag within the application at 

the point of deployment. The first out-pipe involves sending data to the outside world 
. when a delivery order has been accepted. An example of this is configuring the out- 
pipe to be turned on with the email notification service provider. When the delivery 
order is confirmed all the entities needing this information could be notified. 

25 A second out-pipe example is oriented towards the accounts payable 

department. This out-pipe sends information about the receipt of a delivery order. 
This allows accounts payable the ability to start the payment process to the supplier. 
This outpipe might be configured to be turned on using a fax service provider. When 
the eSupplier module receives a delivery order then data would be sent out this 

30 outpipe. The out-pipe would invoke the service provider which in this case would 
send a fax to the point of contact in the accounts payable department. 
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Another out-pipe example involves sending data out when a delivery order is 
late. An example of how it might be configured at deployment is to configure the out- > 
pipe with the message queue service provider. When a delivery order is determined 
to be late the out-pipe would send the message to the message queue. A software 
5 application with the ability to read messages from the asynchronous message queue 
could get the message and then give the appropriate individual visibility into the 
problem. 

These out-pipes can be turned on or off at the point of deployment. In 
addition, they can be configured to use any of the out-pipe service providers. 

10 

AppConfiq Parameters 

A family of application configuration parameters may be implemented for this 
subsystem. The tags and values are listed in Table 13: 



parameterGroup 


parameterGroup 


value 


default 


"eSupplier" 


"startTime" 


hour/minute 


00:00 


"eSupplier 


"stopTime" 


hour/minute 


23:59 



15 

Table 13 



These parameters should be defined for the eSupplier product, or the defaults 
are assumed by this service. 

20 Although the present invention and its advantages have been described in 

detail, it should be understood that various changes, substitutions and alterations 
can be made herein without departing from the spirit and scope of the invention as 
defined by the appended claims. For example, many of the features and functions 
discussed above can be implemented in software, hardware or firmware, or a 

25 combination thereof, running on one or more computers. Moreover, the scope of the 
present application is not intended to be limited to the particular embodiments of the 
process, machine, manufacture, composition of matter, means, methods and steps 
described in the specification. As one of ordinary skill in the art will readily 
appreciate from the disclosure of the present invention, processes, machines, 

30 manufacture, compositions of matter, means, methods, or steps, presently existing 
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or later to be developed, that perform substantially the same function or achieve 
substantially the same result as the corresponding embodiments described herein 
may be utilized according to the present invention. Accordingly, the appended 
claims are intended to include within their scope such processes, machines, 
5 manufacture, compositions of matter, means, methods, or steps. 
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APPENDIX 1 
eCustomer Database Tables 

Object: Table dbo.flCustomerEntity ******/ 

if exists (select * from sysobjects where id = objectjd('dbo.flCustomerEntity') and 
sysstat&Oxf = 3) 
10 drop table dbo.flCustomerEntity 
GO 

CREATE TABLE dbo.flCustomerEntity 
( 

1 5 ndx int IDENTITY (1,1) NOT NULL , 

dateCreated datetime NOT NULL, 

dateModified datetime NULL, 
dateDeleted datetime NULL, 

20 firstName varchar (120) NOT NULL, 

middleName varchar (120) NOT NULL, 

lastName varchar (120) NOT NULL, 

companyName varchar (120) NOT NULL, 

streetl varchar (120) NOT NULL, 

25 street2 varchar (120) NOT NULL, 

street3 varchar (120) NOT NULL, 

city varchar (120) NOT NULL, 

state varchar (1 20) NOT NULL, 

country varchar (120) NOT NULL, 

30 zipCode varchar (120) NOT NULL, 

emailAddress varchar (120) NOT NULL, 

telephoneNumber varchar (120) NOT NULL, 

faxNumber varchar (1 20) NOT NULL, 

35 CONSTRAINT PK_CustomerEntityNdx PRIMARY KEY CLUSTERED 
( 

ndx 

). 

) 

40 GO 

/****** Object: Table dbo.flCustomerAppEntity ******/ 

if exists (select * from sysobjects where id = object_id( , dbo.flCustomerAppEntity') 
45 and sysstat & Oxf = 3) 

drop table dbo.flCustomerAppEntity 
GO 
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CREATE TABLE dbo.flCustomerAppEntity 
( 

ndx int IDENTITY (1,1) NOT NULL , 

5 dateCreated datetime NOT NULL, 

dateModified datetime NULL, 
dateDeleted datetime NULL, 

customerEntityNdx int NOT NULL, 
1 0 name varchar (1 20) NOT NULL, 

type varchar (120) NOT NULL, 

ur! varchar (255) NOT NULL, 

priority int NOT NULL, 

turnedOn int NOT NULL, 

15 

CONSTRAINT PK CustomerAppEntityNdx PRIMARY KEY CLUSTERED 
( 

ndx 

), 

20 ) 
GO 



/****** Object: Table dbo.flCustomerlnfonmation ******/ 

25 if exists (select * from sysobjects where id = objectjd('dbo.flCustomerlnformation') 
andsysstat&0xf=3) 
drop table dbo.flCustomerlnformation 
GO 



30 CREATE TABLE dbo.flCustomerlnformation 



35 



( 



ndx 

dateCreated 
dateModified 
dateDeleted 



int IDENTITY (1,1) NOT NULL , 
datetime NOT NULL, 
datetime NULL, 

datetime NULL, 



40 



customerEntityNdx 

productNdx 

maximumOrderSize 

minimumOrderSize 

customerPriority 



int NOT NULL, 
int NOT NULL, 
NUMERIC(10,4) NOT NULL, 
NUMERIC(10,4) NOT NULL, 
int NOT NULL, 



CONSTRAINT PK_CustomerlnformationNdx PRIMARY KEY CLUSTERED 
( 

45 ndx 

)■ 

CONSTRAINT FK_CICustomerEntityNdx FOREIGN KEY 
( 

50 customerEntityNdx 
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10 



15 ) 



30 



35 



40 



45 



50 



REFERENCES dbo.flCustomerEntity 
ndx 

CONSTRAINT FKCIProductNdx FOREIGN KEY 

productNdx 
REFERENCES dbo.flFactoryProduct 
ndx 



GO 



/****** Object: Table dbo.flCustomerPromiseOrder 



7 



20 if exists (select * from sysobjects where id = 

objectjdCdbo.flCustomerPromiseOrder') and sysstat & Oxf = 3) 
drop table dbo.flCustomerPromiseOrder 
GO 

25 CREATE TABLE dbo.flCustomerPromiseOrder 



( 



ndx 

dateCreated 
dateModified 
dateDeleted 



int IDENTITY (1,1) NOT NULL , 
datetime NOT NULL, 
datetime NULL, 

datetime NULL, 



customerEntityNdx int NOT NULL, 

productNdx int NOT NULL, 

promiseOrderNumber varchar(120) NOT NULL, 

quantity NUMERIC(1 0,4) NOT NULL, 

deliveryDate datetime NOT NULL, 
state varchar (60) NOT NULL, 

CONSTRAINT PK_CustomerPromiseOrderNdx PRIMARY KEY CLUSTERED 

ndx 

CONSTRAINT FKCPOOCustomerEntityNdx FOREIGN KEY 

customerEntityNdx 
REFERENCES dbo.flCustomerEntity 

ndx 
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CONSTRAINT FK_CPOOProductNdx FOREIGN KEY 

( 

productNdx 

5 ) 

REFERENCES dbo.flFactoryProduct 
( 

ndx 

), 

10 ) 
GO 

/*"*** Object: Table dbo.flCustomerPromiseOrderRpt ******/ 

15 if exists (select * from sysobjects where id = 

objectjdCdbo.flCustomerPromiseOrderRpt') and sysstat & Oxf = 3) 
drop table dbo.flCustomerPromiseOrderRpt 
GO 

20 CREATE TABLE dbo.flCustomerPromiseOrderRpt 
( 

ndx int IDENTITY (1,1) NOT NULL , 

dateCreated datetime NOT NULL, 

dateModified datetime NULL, 

25 dateDeleted datetime NULL, 



30 



35 



40 



45 



50 



customerEntityNdx 

productNdx 

quantity 

promiseOate 

startPeriod 

endPeriod 

customerPriority 

state 



int NOT NULL, 
int NOT NULL, 

NUMERIC(10,4) NOT NULL, 
datetime NOT NULL, 
datetime NOT NULL, 
datetime NOT NULL, 

int NOT NULL, 

varchar(60)NOTNULL, 



CONSTRAINT PK CustomerPromiseOrderRptNdx PRIMARY KEY 
CLUSTERED 

ndx 



CONSTRAINT FK_CPORCustomerEntityNdx FOREIGN KEY 

customerEntityNdx 
REFERENCES dbo.flCustomerEntity 
ndx 
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10 



CONSTRAINT FK CPORProductNdx FOREIGN KEY 
( 

productNdx 

) 

REFERENCES dbo.flFactoryProduct 
( 



). 



ndx 



) 

GO 



15 



20 



25 



30 



35 



40 



45 



Object: Table dbo.flCustomerPurchaseOrder ******/ 

if exists (select * from sysobjects where id = 

objectJdCdbo.flCustomerPurchaseOrder') and sysstat & Oxf = 3) 

drop table dbo.flCustomerPurchaseOrder 
GO 

CREATE TABLE dbo.flCustomerPurchaseOrder 
( 

ndx int IDENTITY (1,1) NOT NULL , 

dateCreated datetime NOT NULL, 

dateModified datetime NULL, 

dateDeleted datetime NULL, 

customerEntityNdx int NOT NULL, 

purchaseOrderNumber varchar (255) NOT NULL, 
issueDate datetime NOT NULL, 

amountTotal NUMERIC(12,4) NOT NULL, 

amountConsumed NUMERIC(12,4) NOT NULL, 

CONSTRAINT PK_CustomerPurchaseOrderNdx PRIMARY KEY CLUSTERED 

ndx 



CONSTRAINT FK_CPOCustomerEntityNdx FOREIGN KEY 

customerEntityNdx 
REFERENCES dbo.flCustomerEntity 
ndx 



) 

GO 
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/"**** Object: Table dbo.flCustomerShipping ******/ 

if exists (select * from sysobjects where id = objecUd( , dbo.flCustomerShipping') and 
5 sysstat & Qxf = 3) 

drop table dbo.flCustomerShipping 
GO 

CREATE TABLE dbo.flCustomerShipping 
10 ( 

ndx int IDENTITY (1,1) NOT NULL , 

dateCreated datetime NOT NULL, 

dateModified datetime NULL, 

dateDeleted datetime NULL, 

15 

promiseOrderNdx int NOT NULL, 

shipperOptionNdx int NOT NULL, 

CONSTRAINT PKCustomerShippingNdx PRIMARY KEY CLUSTERED 
20 ( 

ndx 



CONSTRAINT FK_CSCustomerPromiseOrderNdx FOREIGN KEY 
25 ( 

promiseOrderNdx 
REFERENCES dbo.flCustomerPromiseOrder 
30 ndx 



CONSTRAINT FK_CSShipperOptionNdx FOREIGN KEY 
35 shipperOptionNdx 

REFERENCES dbo.flServicesShipperOption 
ndx 

40 ), 
) 

GO 

Object: Table dbo.flCustomerTemplate ******/ 

45 

if exists (select * from sysobjects where id = objectjdCdbo.flCustomerTemplate') and 
sysstat & Oxf = 3) 

drop table dbo.flCustomerTemplate 
GO 

50 
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CREATE TABLE dbo.flCustomerTemplate 
( 

ndx int IDENTITY (1, 1) NOT NULL, 

5 dateCreated datetime NOT NULL, 

dateModified datetime NULL, 

dateDeleted datetime NULL, 



10 



15 



20 



25 



30 



35 



customerEntityNdx 

productNdx 

quantity 

tag 



int NOT NULL, 
int NOT NULL, 
NUMERIC(10,4) NOT NULL, 
varchar(120) NOT NULL, 



CONSTRAINT PK_CustomerTemplateNdx PRIMARY KEY CLUSTERED 
ndx 

CONSTRAINT FK_CPOTCustomerEntityNdx FOREIGN KEY 

customerEntityNdx 
REFERENCES dbo.flCustomerEntity 
ndx 

CONSTRAINT FK_CPOTProductNdx FOREIGN KEY 

productNdx 
REFERENCES dbo.flFactoryProduct 
ndx 



) 

GO 
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APPENDIX 2 
eSupplier Database Tables 

5 

/****** Object: Table dbo.flSupplierEntity ******/ 

If exists (select * from sysobjects where id = objectjd('dbo.flSupplierEntity') and 
sysstat&Oxf = 3) 
10 drop table dbo.flSupplierEntity 
GO 

CREATE TABLE dbo.flSupplierEntity 
( 

1 5 ndx int IDENTITY (1,1) NOT NULL , 

dateCreated datetime NOT NULL, 
dateModified datetime NULL, 
dateDeleted datetime NULL, 

20 firstName varchar (120) NOT NULL, 

middleName varchar (1 20) NOT NULL, 

lastName varchar (1 20) NOT NULL, 

company Name varchar (120) NOT NULL, 

streetl varchar (1 20) NOT NULL, 

25 street2 varchar (1 20) NOT NULL, 

street3 varchar (120) NOT NULL, 

city varchar (120) NOT NULL, 

state varchar (1 20) NOT NULL, 

country varchar (120) NOT NULL, ^ 

30 zipCode varchar (120) NOT NULL, 

emailAddress varchar (120) NOT NULL, 
telephoneNumber varchar (120) NOT NULL, 
faxNumber varchar (1 20) NOT NULL, 

35 CONSTRAINT PK_SupplierEntityNdx PRIMARY KEY CLUSTERED 
( 

ndx 

). 

) 

40 GO 

/***"* Object: Table dbo.flSupplierPart ******/ 

if exists (select * from sysobjects where id = objectjd('dbo.flSupplierPart') and 
45 sysstat & Oxf = 3) 

drop table dbo.flSupplierPart 
GO 
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CREATE TABLE dbo.flSupplierPart 
( 



10 



15 



25 



30 



35 



40 



45 



50 



ndx 

dateCreated 
dateModified 
dateDeleted 

name 

code 

uom 



int IDENTITY (1,1) NOT NULL , 
datetime NOT NULL, 
datetime NULL, 
datetime NULL, 

varchar (120) NOT NULL , 
varchar (60) NOT NULL , 
varchar (60) NOT NULL, 



CONSTRAINT PK_PartNdx PRIMARY KEY CLUSTERED 
( 

ndx 



) 

) 

GO 

20 /****** Object: Table dbo.flSupplierPartStock 



/ 



if exists (select * from sysobjects where id = objectj'd('dbo.flSupplierPartStock') and 

sysstat&Oxf = 3) 

drop table dbo.flSupplierPartStock 
GO 

CREATE TABLE dbo.flSupplierPartStock 



( 



ndx 

dateCreated 
dateModified 
dateDeleted 



int IDENTITY (1,1) NOT NULL , 
datetime NOT NULL, 
datetime NULL, 

datetime NULL, 



partNdx int NOT NULL, 

quantity NUMERIC(12,4) NOT NULL, 

supplierOrderNumber varchar( 60 ) NOT NULL, 
supplierOrderAlias varchar( 60 ) NOT NULL, 
availabilityDate datetime NOT NULL, 

CONSTRAINT PK_PartStockNdx PRIMARY KEY CLUSTERED 

ndx 

CONSTRAINT FK_SPSStockPartNdx FOREIGN KEY 
partNdx 

REFERENCES dbo.flSupplierPart 
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ndx 



10 



15 



20 



25 



30 



35 



40 



), 



) 

GO 



/"**** Object: Table dbo.flSupplierPartStockComponent 

if exists (select * from sysobjects where id = 

objectj'dCdbo.flSupplierPartStockComponenf) and sysstat & Oxf = 3) 

drop table dbo.flSupplierPartStockComponent 
GO 

CREATE TABLE dbo.flSupplierPartStockComponent 
( 



ndx 

dateCreated 
dateModified 
dateDeleted 



int IDENTITY (1,1) NOT NULL , 
datetime NOT NULL, 
datetime NULL, 

datetime NULL, 



partNdx int NOT NULL, 

partName varchar( 60 ) NOT NULL, 

partCode varchar( 60 ) NOT NULL, 

supplierOrderNumber varchar( 60 ) NOT NULL, 

supplierOrderAlias varchar( 60 ) NOT NULL, 

quantity NUMERIC(10,4) NOT NULL, 
description varchart 255 ) NOT NULL, 

availabilityDate datetime NOT NULL, 



CONSTRAINT PK_PartStockComponentNdx PRIMARY KEY CLUSTERED 
ndx 

CONSTRAINT FK_SPSCStockPartNdx FOREIGN KEY 
partNdx 

REFERENCES dbo.flSupplierPart 
ndx 



) 

GO 



45 r 



Object: Table dbo.flSupplierBom 



7 



50 



if exists (select * from sysobjects where id = objectJd('dbo.flSupplierBom') and 

sysstat & Oxf = 3) 

drop table dbo.flSupplierBom 
GO 
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CREATE TABLE dbo.flSupplierBom 
( 

ndx int IDENTITY (1,1) NOT NULL , 

5 dateCreated datetime NOT NULL, 

dateModified datetime NULL, 
dateDeleted datetime NULL, 

partNdx int NOT NULL, 

10 parentProductNdx int NOT NULL, 

quantity NUMERIC(10,4) NOT NULL, 

CONSTRAINT PK_SupplierBomNdx PRIMARY KEY CLUSTERED 

15 ndx 



CONSTRAINT FK_SBPartNdx FOREIGN KEY 
20 partNdx 

REFERENCES dbo.flSupplierPart 
ndx 

25 ), 

CONSTRAINT FK_SBParentProductNdx FOREIGN KEY 
parentProductNdx 

30 ) 

REFERENCES dbo.flFactoryProduct 

ndx 

35 ) 
GO 



/****** Object: Table dbo.flSupplierDeliveryOrderRpt "****/ 

40 

if exists (select * from sysobjects where id = 

object_id('dbo.flSupplierDeliveryOrderRpt') and sysstat & Oxf = 3) 

drop table dbo.flSupplierDeliveryOrderRpt 
GO 

45 

CREATE TABLE dbo.flSupplierDeliveryOrderRpt 
( 

ndx int IDENTITY (1,1) NOT NULL , 

dateCreated datetime NOT NULL, 

50 dateModified datetime NULL, 

FAC001 60 



WO 01/73651 



PCT/US01/08771 



dateDeleted 



datetime NULL, 



10 



15 



20 



25 



30 



35 



supplierEntityNdx int NOT NULL, 

partNdx int NOT NULL, 

quantity NUMERIC(1 0,4) NOT NULL, 

deliveryDate datetime NOT NULL, 

startPeriod datetime NOT NULL, 

endPeriod datetime NOT NULL, 

supplierPriority int NOT NULL, 

state varchar (60) NOT NULL, 

CONSTRAINT PK_SupplierDeliveryOrderRptNdx PRIMARY KEY CLUSTERED 
ndx 

CONSTRAINT FK_DORSupplierEntityNdx FOREIGN KEY 

supplierEntityNdx 
REFERENCES dbo.flSupplierEntity 
ndx 

CONSTRAI NT FK.DORPartNdx FOREIGN KEY 
partNdx 

REFERENCES dbo.flSupplierPart 
ndx 



) 

GO 



/****" Object: Table dbo.flSupplierReOrderPoints ****"/ 

if exists (select * from sysobjects where id = object_id('dbo.f!SupplierReOrderPoints') 
40 and sysstat & Oxf = 3) 

drop table dbo.flSupplierReOrderPoints 
GO 



CREATE TABLE dbo.flSupplierReOrderPoints 
45 ( 

ndx int IDENTITY (1,1) NOT NULL , 

dateCreated datetime NOT NULL, 

dateModified datetime NULL, 
dateDeleted datetime NULL, 
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partNdx int NOT NULL, 

reOrderPoint NUMERIC(1 0,4) NOT NULL, 
quantity NUMERIC(1 0,4) NOT NULL, 



CONSTRAINT PK»SupplierReOrderPointsNdx PRIMARY KEY CLUSTERED 
ndx 

10 ), 

CONSTRAINT FKSROPPartNdx FOREIGN KEY 
partNdx 

15 ) 

REFERENCES dbo.flSupplierPart 

ndx 

20 ) 
GO 

/****" Object: Table dbo.flSupplierScheduleRpt ******/ 

25 if exists (select * from sysobjects where id = object_id('dbo.flSupplierScheduleRpf) 
and sysstat & Oxf = 3) 
drop table dbo.flSupplierScheduleRpt 
GO 



CREATE TABLE dbo.flSupplierScheduleRpt 
( 

ndx int IDENTITY (1,1) NOT NULL , 

dateCreated datetime NOT NULL, 

dateModified datetime NULL, 
dateDeleted datetime NULL, 

workOrderNumber varchar (60) NOT NULL, 
productNdx int NOT NULL, 

workCenterNdx int NOT NULL, 
40 partNdx int NOT NULL, 

quantity NUMERIC(10,4) NOT NULL, 

startTime datetime NOT NULL, 
issueDate datetime NOT NULL, 



45 CONSTRAINT PK_SupplierScheduleRptNdx PRIMARY KEY CLUSTERED 
( 

ndx 

). 

50 CONSTRAINT FK_SSRProductNdx FOREIGN KEY 
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productNdx 
REFERENCES dbo.flFactoryProduct 
ndx 

CONSTRAINT FK_SSRWorkCenterNdx FOREIGN KEY 

workCenterNdx 
REFERENCES dbo.flFactoryWorkCenter 
ndx 

CONSTRAINT FK_SSRPartNdx FOREIGN KEY 
partNdx 

REFERENCES dbo.flSupplierPart 
ndx 



GO 



/"**** Object: Table dbo.flSupplierAppEntity ****"/ 

30 

if exists (select * from sysobjects where id = object_id( , dbo.flSupplierAppEntity') and 

sysstat&Oxf = 3) 

drop table dbo.flSupplierAppEntity 
GO 

35 

CREATE TABLE dbo.flSupplierAppEntity 
( 

ndx int IDENTITY (1.1) NOT NULL , 

dateCreated datetime NOT NULL, 

40 dateModifled datetime NULL, 

dateDeleted datetime NULL, 

supplierEntityNdx int NOT NULL, 
name varchar (1 20) NOT NULL, 

45 type varchar (120) NOT NULL, 

url varchar (255) NOT NULL, 

priority int NOT NULL, 

tumedOn int NOT NULL, 

50 CONSTRAINT PKSupplierAppEntityNdx PRIMARY KEY CLUSTERED 
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15 



20 



25 



30 



35 



40 



45 



50 



ndx 

CONSTRAINT FKSAESupplierEntityNdx FOREIGN KEY 

supplierEntityNdx 
REFERENCES dbo.flSupplierEntity 
ndx 



) 

GO 

/****** Object: Table dbo.flSupplierlnformation . ******/ 



if exists (select * from sysobjects where id = object_id('dbo.flSupplierinformation') 

and sysstat & Oxf = 3) 

drop table dbo.flSupplierlnformation 
GO 

CREATE TABLE dbo.flSupplierlnfonnation 
( 



ndx 

dateCreated 
dateModified 
dateDeleted 

supplierEntityNdx 
partNdx 

capacityPerDay 
minimumOrderSize 
supplierPriority 
leadTime 



int IDENTITY (1,1) NOT NULL , 
datetime NOT NULL, 
datetime NULL, 

datetime NULL, 

int NOT NULL, 
int NOT NULL, 
NUMERIC(10,4) NOT NULL, 

NUMERIC(10,4) NOT NULL, 
int NOT NULL, 
NUMERIC(12,4) NOT NULL, 



CONSTRAINT PK_SupplierlnformationNdx PRIMARY KEY CLUSTERED 
ndx 

CONSTRAINT FK_SISupplier£ntityNdx FOREIGN KEY 

supplierEntityNdx 
REFERENCES dbo.flSupplierEntity 
ndx 
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10 



15 



CONSTRAINT FK_SIPartNdx FOREIGN KEY 
( 

• partNdx 

) 

REFERENCES dbo.flSupplierPart 
( 



ndx 



). 



) 

GO 

/****** Object: Table dbo.flSupplierDeliveryOrcler 



7 



if exists (select * from sysobjects where id = objectjd('dbo.flSupplierDeliveryOrder') 

and sysstat & Oxf = 3) 

drop table dbo.flSupplierDeliveryOrder 
GO 



20 ( 



25 



30 



35 



40 



45 



50 



CREATE TABLE dbo.flSupplierDeliveryOrder 



ndx 

dateCreated 
dateModified 
dateDeleted 



int IDENTITY (1,1) NOT NULL , 
datetime NOT NULL, 
datetime NULL, 

datetime NULL, 



supplierEntityNdx int NOT NULL, 

partNdx int NOT NULL, 

deliveryOrderNumber varchar (120) NOT NULL, 

quantity NUMERIC(10,4) NOT NULL, 

deliveryDate datetime NOT NULL, 
state varchar (60) NOT NULL, 

CONSTRAINT PK_SupplierDeliveryOrderNdx PRIMARY KEY CLUSTERED 

ndx 

CONSTRAINT FKDOSupplierEntityNdx FOREIGN KEY 

supplierEntityNdx 
REFERENCES dbo.flSupplierEntity 
ndx 

CONSTRAINT FK_DOPartNdx FOREIGN KEY 
i partNdx 
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20 



25 



30 



35 



40 



45 



REFERENCES dbo.flSupplierPart 

( 



). 



) 

GO 



ndx 



Object: Table dbo.flSupplierHistory 



*l 



1 0 if exists (select * from sysobjects where id = object_id( , dbo.flSupplierHistory') and 
sysstat&0xf=3) 
" drop table dbo.flSupplierHistory 
GO 

1 5 CREATE TABLE dbo.flSupplierHistory 



( 



ndx 

dateCreated 
dateModified 
dateDeleted 

supplierEntityNdx 

partNdx 

quantity 

targetDeliveryDate 
actualDeliveryDate 



int IDENTITY (1,1) NOT NULL , 
datetime NOT NULL, 
datetime NULL, 

datetime NULL, 

int NOT NULL, 
int NOT NULL, 
NUMERIC(10,4) NOT NULL, 
datetime NOT NULL, 
datetime NOT NULL, 



CONSTRAINT PK_SupplierHistoryNdx PRIMARY KEY CLUSTERED 
ndx 

CONSTRAINT FK_DOHSupplierEntityNdx FOREIGN KEY 

supplierEntityNdx 
REFERENCES dbo.flSupplierEntity 
ndx 

CONSTRAINT FKDOHPartNdx FOREIGN KEY 
partNdx 

REFERENCES dbo.flSupplierPart 
ndx 



50 ) 
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GO 

/****** Object: Table dbo.flSupplierPurchaseOrder ******/ 

5 if exists (select * from sysobjects where id = objectJd('dbo.flSupplierPurchaseOrder') 
andsysstat&0xf = 3) 
drop table dbo.flSupplierPurchaseOrder 
GO 

1 0 CREATE TABLE dbo.flSupplierPurchaseOrder 
( 

ndx int IDENTITY (1,1) NOT NULL , 

dateCreated datetime NOT NULL. 

dateModified datetime NULL, 

15 dateDeleted datetime NULL, 

supplierEntityNdx int NOT NULL, 

purchaseOrderNumber varchar (255) NOT NULL, 
issueDate datetime NOT NULL, 

20 amountTotal NUMERIC(12,4) NOT NULL, 

amountConsumed NUMERIC(12.4) NOT NULL, 

CONSTRAINT PK_SupplierPurchaseOrderNdx PRIMARY KEY CLUSTERED 
( 

25 ndx 

). 

) 

GO 

30 /"**** Object: Table dbo.flSupplierReceiving ******/ 

if exists (select * from sysobjects where id = objectjd('dbo.flSupplierReceiving') and 
sysstat & Oxf = 3) 
drop table dbo.flSupplierReceiving 
35 GO 

CREATE TABLE dbo.flSupplierReceiving 
( 

ndx int IDENTITY (1,1) NOT NULL , 

40 dateCreated datetime NOT NULL, 

dateModified datetime NULL, 

dateDeleted datetime NULL, 

deliveryOrderNdx int NOT NULL, 

45 shipperOptionNdx int NOT NULL, 



CONSTRAINT PK SupplierReceivingNdx PRIMARY KEY CLUSTERED 
( 

50 ndx 
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15 



20 



35 



40 



45 



50 



CONSTRAINT FKCRSupplierDeliveryOrderNdx FOREIGN KEY 

deliveryOrderNdx 
REFERENCES dbo.flSupplierDeliveryOrder 
ndx 

CONSTRAINT FKCRShipperOptionNdx FOREIGN KEY 

shipperOptionNdx 
REFERENCES dbo.flServicesShipperOption 
ndx 



) 

GO 

/****" Object: Table dbo.flSupplierRunningStock *"***/ 

25 if exists (select * from sysobjects where id = objectjdCdbo.flSupplierRunningStock') 
arid sysstat & Oxf = 3) 
drop table dbo.flSupplierRunningStock 
GO 

30 CREATE TABLE dbo.flSupplierRunningStock 



( 



ndx 

dateCreated 
dateModified 
dateDeleted 

partNdx 
quantity 

lastDeliveryOrderNumber 
lastDeiiveryDate 
alias 



int IDENTITY (1,1) NOT NULL , 
datetime NOT NULL, 
datetime NULL, 

datetime NULL, 

int NOT NULL, 
int NOT NULL, 
varchar(60)NOT NULL, 
datetime NOT NULL, 



varchar( 60 ) NOT NULL, 



CONSTRAINT PK_RunningStockNdx PRIMARY KEY CLUSTERED 
( 



). 



ndx 



CONSTRAINT FKSRSRunningStockPartNdx FOREIGN KEY 
( 



partNdx 
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) 

REFERENCES dbo.flSupplierPart 
( 

5 ndx 

). 

) 

GO 
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WHAT IS CLAIMED IS: 

1. A computer implemented method of managing mass customized product 
manufacturing in a factory, said method comprising: 

5 receiving an order for a customized product, said order comprising base 

information for said customized product; 

dynamically determining manufacturing parameters for manufacturing said 
customized product based on said product base information; and 

scheduling manufacture of said customized product in said factory based upon 
10 finite capacity loading of said factory using said manufacturing parameters. 

2. The method of claim 1 , wherein said order further comprises option information for 
said customized product, and wherein said dynamically determining said manufacturing 
parameters is further based on said product option information. 

15 

3. The method of claim 2 wherein said base information corresponds to a particular 
stock keeping unit independent of said option information. 

4. The method of claim 1 , wherein said manufacturing parameters are selected from 
20 the group consisting of: capacity, labor, bill of materials, work content, and 

combinations thereof. 

5. The method of claim 1, said method further comprising synchronizing raw material 
supplies with said customized product manufacture. 

25 

6. The method of claim 1, said method further comprising coordinating delivering of 
said customized product upon completion of said customized product. 

7. The method of claim 1, wherein said determining said manufacturing parameters 
30 further comprises obtaining said manufacturing parameters remotely via an intranet or 

internet. 

8. The method of claim 1, wherein said order is received via an intranet or internet. 
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9. The method of claim 8, wherein said order is received in extended markup language 
format. 

10. The method of claim 1, said method further comprising providing to a requester of 
5 said order a real-time available-to-promise date based on said manufacturing 

parameters and on said finite capacity loading. 

1 1 . A computer implemented method of managing mass customized product 
10 manufacturing in a factory, said method comprising: 

receiving an order for a customized product from an order requester, said order 
comprising base information for said customized product; and 

providing to said order requester a real-time available-to-promise date based on 
finite capacity loading of said factory. 

15 

12. The method of claim 1 1 , wherein said order is received via an intranet or internet. 

13. The method of claim 12, wherein said order is received in extended markup 
language format 

20 

14. The method of claim 1 1 , wherein said factory utilizes a make-to-order 
manufacturing process. 

15. The method of claim 1 1 , wherein said factory utilizes an order booking 
25 manufacturing process. 

16. The method of claim 1 1 , said method further comprising dynamically determining 
manufacturing parameters for manufacturing said customized product based on said 
product base information. 

30 

17. The method of claim 16, said method further comprising basing said available-to- 
promise date on said manufacturing parameters in addition to said finite capacity 
loading. 
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18. The method of claim 16, said method further comprising scheduling manufacture of 
said customized product in said factory based upon said finite capacity loading using 
said manufacturing parameters. 

5 19. The method of claim 16, wherein said manufacturing parameters are selected from 
the group consisting of: capacity, labor, bill of materials, work content, and 
combinations thereof. 

20. The method of claim 16, wherein said order further comprises option information for 
10 said customized product, and wherein said dynamically determining said manufacturing 

parameters is further based on said product option information. 

21 . The method of claim 20 wherein said base information corresponds to a particular 
stock keeping unit independent of said option information. 

15 

22. A computer program product including computer readable logic recorded thereon 
for managing mass customized product manufacturing in a factory, the computer 
program product comprising: 

20 a computer-readable storage medium; and 

a computer program stored on the computer-readable storage medium, the 
computer program comprising 

instructions for receiving an order for a customized product, said order 
comprising base information for said customized product; 
25 instructions for dynamically determining manufacturing parameters for 

manufacturing said customized product based on said product base information; and 

instructions for scheduling manufacture of said customized product in said 
factory based upon finite capacity loading of said factory using said manufacturing 
parameters. 

30 

23. The computer program of claim 22, wherein said order further comprises option 
information for said customized product, and wherein said method further comprises 
instructions for dynamically determining said manufacturing parameters for 
manufacturing said customized product based on said product option information. 
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24. The computer program of claim 23 wherein said base information corresponds to a 
particular stock keeping unit independent of said option information. 

5 25. The computer program of claim 22, wherein said manufacturing parameters are 
selected from the group consisting of: capacity, labor, bill of materials, work content, 
and combinations thereof. 

26. The computer program of claim 22, further comprising instructions for synchronizing 
10 raw material supplies with said customized product manufacture. 

27. The computer program of claim 22, further comprising instructions for coordinating 
delivering of said customized product upon completion of said customized product. 

15 28. The computer program of claim 22, wherein said computer program is a distributed 
software application. 

29. The computer program of claim 22, wherein said instructions for determining said 
manufacturing parameters further comprise instructions for obtaining said manufacturing 

20 parameters remotely via an intranet or internet. 

30. The computer program of claim 22, wherein said instructions for receiving said 
order further comprise instructions for receiving said order via an intranet or internet. 

25 31 . The computer program of claim 30, wherein said order is in extended markup 
language format. 

32. The computer program of claim 22 f further comprising instructions for providing to a 
requestor of said order a real-time available-to-promise date based on said 
30 manufacturing parameters and on said finite capacity loading. 
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33. A computer program product including computer readable logic recorded thereon 
for managing mass customized product manufacturing in a factory, the computer 
program product comprising: 

a computer-readable storage medium; and 
5 a computer program stored on the computer-readable storage medium, the 

computer program comprising 

instructions for receiving an order for a customized product from an order 
requester, said order comprising base information for said customized product; and 

instructions for providing to said order requester a real-time available-to- 
10 promise date based on finite capacity loading of said factory. 



34. A method of manufacturing a product in a factory, said method comprising: 

receiving an order for a customized product, said order comprising base 
1 5 information for said customized product; 

dynamically determining manufacturing parameters for manufacturing said 
customized product based on said product base information; and 

scheduling manufacture of said customized product in said factory based upon 
finite capacity loading of said factory using said manufacturing parameters. 

20 

35. The customized product manufactured by the method of claim 34. 



36. A system for managing mass customized product manufacturing in a factory, said 
25 system comprising: 

means for receiving an order for a customized product, said order comprising 
base information for said customized product; 

means for dynamically determining manufacturing parameters for manufacturing 
said customized product based on said product base information; and 
30 means for scheduling manufacture of said customized product in said factory 

based upon finite capacity loading of said factory using said manufacturing parameters. 
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37. A system for managing mass customized product manufacturing in a factory, said 
system comprising: 

means for receiving an order for a customized product from an order requester, 
said order comprising base information for said customized product; and 
5 means for providing to said order requester a real-time available-to-promise date 

based on finite capacity loading of said factory. 
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